home *** CD-ROM | disk | FTP | other *** search
/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / mac / faqs.381 < prev    next >
Text File  |  1996-02-12  |  29KB  |  721 lines
  1. Frequently Asked Questions (FAQS);faqs.381
  2.  
  3.  
  4.  
  5. Answer: Motif 1.0 has many memory leaks, particularly in XmString
  6. manipulation.  Switch to Motif 1.1.
  7.  
  8. Answer: The Intrinsics have a memory leak in accelerator table management, and
  9. Motif uses this heavily.  Avoid this by mapping/unmapping widgets rather than
  10. creating/destroying them, or get  X11R4 fix-15/16/17.
  11.  
  12. Answer: The server may grow in size due to its own memory leaks.  Switch to a
  13. later server.
  14.  
  15. Answer: You are responsible for garbage collection in `C'.  Some common cases
  16. where a piece of memory becomes garbage are
  17.  
  18.  a.  Memory is allocated by Motif for XmStrings by the functions
  19.      XmStringConcat, XmStringCopy, XmStringCreate, XmStringCreateLtoR,
  20.      XmStringCreateSimple, XmStringDirectionCreate, XmStringNConcat,
  21.      XmStringNCopy, XmStringSegmentCreate, and XmStringSeparatorCreate.  The
  22.      values returned by these functions should be freed using XmStringFree
  23.      when they are no longer needed.
  24.  
  25.  b.  Memory is allocated by Motif for ordinary character strings (of type
  26.      String) by Motif in XmStringGetLtoR, XmStringGetNextComponent, and
  27.      XmStringGetNextSegment. After using the string, XtFree() it. [Note that
  28.      XmStrings and Strings are two different data types.  XmStrings are
  29.      XmStringFree'd, Strings are XtFree'd.]
  30.  
  31.  c.  If you have set the label (an XmString) in a label, pushbutton, etc
  32.      widget, free it after calling XtSetValues() or the widget creation
  33.      routine by XmStringFree().
  34.  
  35.  d.  If you have set text in a text widget, the text widget makes its own
  36.      copy.  Unless you have a use for it, there is no need to keep your own
  37.      copy.
  38.  
  39.  e.  If you have set the strings in a list widget the list widget makes its
  40.      own copy.  Unless you have a use for it, there is no need to keep your
  41.      own copy.
  42.  
  43.  f.  When you get the value of a single compound string from a Widget e.g.
  44.      XmNlabelString, XmNmessageString, ... Motif gives you a copy of its
  45.      internal value.  You should XmStringFree this when you have finished with
  46.      it.
  47.  
  48.  g.  On the other hand, when you get a value of a Table e.g. XmStringTable for
  49.      a List, you get a *pointer* to the internal Table, and should not free
  50.      it.
  51.  
  52.  h.  When you get the value of the text in a widget by XmTextGetString or from
  53.      the resource XmNvalue, you get a copy of the text.  You should XtFree
  54.      this when you have finished with it.
  55.  
  56. Answer: From Josef Nelissen: at least in Motif 1.1.4, X11R4 on a HP 720, the
  57. XmText/XmTextFieldSetString() functions have a memory leak.  The old
  58. value/contents of the Widget isn't freed correctly.  To work around this bug,
  59. one should use a XmText Widget (in single-line-mode) instead of a XmTextField
  60. Widget (the solution fails with XmTextField Widgets !) and replace any
  61.  
  62.        XmTextSetString(text_widget, str);
  63.  
  64. by
  65.  
  66.        XmTextReplace(text_widget, (XmTextPosition) 0,
  67.                      XmTextGetLastPosition(text_widget), str);
  68.  
  69.  
  70. -----------------------------------------------------------------------------
  71. Subject: 86) Why does my application take a long time to start up?
  72.  
  73. Answer: You are probably creating too many widgets at startup time.  Delay
  74. creating them until needed.  If you have a large number of resources in text
  75. files (such as in app-defaults), time may be spent reading and parsing it.
  76.  
  77. -----------------------------------------------------------------------------
  78. Subject: 87) My application is running too slowly. How can I speed it up?
  79.  
  80. Answer: Use the R4 rather than R3 server.  It is much faster.
  81.  
  82. Answer: The standard memory allocator is not well tuned to Motif, and can
  83. degrade performance.  Use a better allocator.  e.g. with SCO Unix, link with
  84. libmalloc.a; use the allocator from GNU emacs; use the allocator from Perl.
  85.  
  86. Answer: Avoid lots of widget creation and destruction.  It fragments memory
  87. and slows everything down.  Popup/popdown, manage/unmanage instead.
  88.  
  89. Answer: Set mappedWhenManaged to FALSE, and then call XtMapWidget()
  90. XtUnmapWidget() rather than managing.
  91.  
  92. Answer: Get more memory - your application, the server and the Operating
  93. System may be spending a lot of time being swapped.
  94.  
  95. Answer: If you are doing much XmString work yourself, such as heavy use of
  96. XmStringCompare, speed may deteriorate due to the large amount of internal
  97. conversions and malloc'ing.  Try using XmStringByteCompare if appropriate or
  98. ordinary Ascii strings if you can.
  99.  
  100.  
  101.  
  102. -----------------------------------------------------------------------------
  103. END OF PART THREE
  104. --
  105. +----------------------+---+
  106.   Jan Newmarch, Information Science and Engineering,
  107.   University of Canberra, PO Box 1, Belconnen, Act 2616
  108.   Australia. Tel: (Aust) 6-2012422. Fax: (Aust) 6-2015041
  109. Xref: bloom-picayune.mit.edu comp.windows.x.motif:13660 news.answers:4511
  110. Newsgroups: comp.windows.x.motif,news.answers
  111. Path: bloom-picayune.mit.edu!enterpoop.mit.edu!news.media.mit.edu!micro-heart-of-gold.mit.edu!wupost!uunet!munnari.oz.au!manuel.anu.edu.au!csc.canberra.edu.au!news
  112. From: jan@ise.canberra.edu.au (Jan Newmarch)
  113. Subject: Motif FAQ (Part 4 of 5)
  114. Message-ID: <1992Dec10.001632.10561@csc.canberra.edu.au>
  115. Followup-To: comp.windows.x.motif
  116. Keywords: FAQ question answer
  117. Sender: news@csc.canberra.edu.au
  118. Reply-To: jan@ise.canberra.edu.au (Jan Newmarch)
  119. Organization: University of Canberra
  120. Date: Thu, 10 Dec 92 00:16:32 GMT
  121. Approved: news-answers-request@MIT.Edu
  122. Expires: +1 months
  123. Lines: 942
  124.  
  125. Archive-name: motif-faq/part4
  126. Last-modified: Thu December 12 1992
  127. Version: 2.12
  128.  
  129.  
  130.  
  131.  
  132. -----------------------------------------------------------------------------
  133. Subject: 88) TOPIC: XMSTRING
  134.  
  135. -----------------------------------------------------------------------------
  136. Subject: 89) How can I get the Ascii text out of an XmString?
  137.  
  138. Answer: To get the first line of text from a string created left-to-right
  139.  
  140.  
  141.         char *str;
  142.         XmString xmstr;
  143.  
  144.         /* stuff to create xmstr */
  145.         ...
  146.  
  147.         /* set str to point to the text */
  148.         XmStringGetLtoR(xmstr, XmSTRING_DEFAULT_CHARSET, &str);
  149.         /* use the string */
  150.         ...
  151.  
  152.         /* and reclaim space */
  153.         XtFree(str);
  154.  
  155.  
  156. -----------------------------------------------------------------------------
  157. Subject: 90) When can XmStrings used as resources be freed?
  158.  
  159. Answer: The policy OSF have been trying to enforce is that if you set an
  160. XmString or XmStringTable resource, the application is responsible for freeing
  161. the XmStrings used because the widget makes a copy.  If you get an XmString
  162. resource, then the application must free the value gotten.  If you get an
  163. XmStringTable, then the application should NOT free the value gotten.  If the
  164. application wants to manipulate it, it should make a copy first. This policy
  165. appears to be implemented progressively, so may be less true for Motif 1.0
  166. than 1.1.
  167.  
  168. -----------------------------------------------------------------------------
  169. Subject: 91) Why doesn't XmStringGetNextSegment() work properly?
  170.  
  171. Answer: The documentation in Motif 1.0 is in error. Instead of
  172.  
  173.         XmStringGetnextSegment(context, ...)
  174.         XmStringContext * context;
  175.  
  176. it should be
  177.  
  178.         XmStringGetnextSegment(context, ...)
  179.         XmStringContext context;
  180.  
  181. i.e. with no indirection.
  182.  
  183. -----------------------------------------------------------------------------
  184. Subject: 92) TOPIC: DIALOGS
  185.  
  186. -----------------------------------------------------------------------------
  187. Subject: 93) How do I stop my dialog disappearing when I press the help
  188. button?
  189.  
  190. Answer: Bulletin board has the resource autoUnmanage which defaults to True.
  191. This unmanages the widget when any button child is activated - including the
  192. help button.  Set this to False to stop it disappearing. Note that you then
  193. have to unmanage the bulletin board yourself when any other button is
  194. activated.
  195.  
  196. -----------------------------------------------------------------------------
  197. Subject: 94) How do I make my own dialog?  I want a dialog with my own set of
  198. buttons that stretch and shrink like the ones in e.g. PromptDialog and its own
  199. contents.
  200.  
  201. Answer: Start off with say a PromptDialog. Unmanage the buttons you don't want
  202. or manage the Apply button if you want another. Unmanage the other bits of the
  203. selection box you don't want. You can add another WorkArea child to the
  204. selection box for any extra stuff you want.
  205.  
  206.     /* Copyright 1990, Kee Hinckley and Brian Holt Hawthorne */
  207.     /* Permission granted for any use, provided this copyright */
  208.     /* notice is maintained. */
  209.  
  210.     /* Create a dialog box */
  211.     argcount = setArgs(&args, XmNautoUnmanage, False, NULL);
  212.     SomeDialog = XmCreatePromptDialog(mainShell, "someDialog", args, argcount);
  213.  
  214.     /* Now get rid of the things we don't want */
  215.     child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_SELECTION_LABEL);
  216.     XtUnmanageChild(child);
  217.     child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_TEXT);
  218.     XtUnmanageChild(child);
  219.  
  220.     /* set the callbacks, and make sure the buttons we want are there */
  221.     child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_OK_BUTTON);
  222.     XtAddCallback(child, XmNactivateCallback, callSomeFunc, someArg);
  223.     XtAddCallback(child, XmNactivateCallback, unManage, SomeDialog);
  224.     XtManageChild(child);
  225.     child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_APPLY_BUTTON);
  226.     XtAddCallback(child, XmNactivateCallback, callSomeFunc, someOtherArg);
  227.     XtManageChild(child);
  228.     child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_CANCEL_BUTTON);
  229.     XtAddCallback(child, XmNactivateCallback, dialogUnmanage, SomeDialog);
  230.     XtManageChild(child);
  231.  
  232.     /* Add a new work area. This can be any manager. */
  233.     child = XmCreateForm(SomeDialog, "someForm", NULL, 0);
  234.     XtManageChild(child);
  235.  
  236.     /* and fill it up... */
  237.     something = doYourStuff(child);
  238.  
  239.  
  240.  
  241. -----------------------------------------------------------------------------
  242. Subject: 95) How come the title bars for my dialogs now have "_popup" or "<-
  243. popup" concatenated onto the widget name?
  244.  
  245.  
  246. Answer: Motif 1.0.3 (?) "fixed" things such that title bars without an
  247. explicit dialogTitle setting use the widget name with "_popup" or whatever
  248. added on.  Set the dialogTitle resource explicitly if you don't want this new
  249. default naming scheme.
  250.  
  251. -----------------------------------------------------------------------------
  252. Subject: 96) How can I force a dialog window to display?  I manage a "working"
  253. dialog, and do some computing, but the dialog window appears blank until the
  254. work has finished.  How can I force it to be displayed?
  255.  
  256. Answer: Use this.  (David Brooks, Systems Engineering, Open Software
  257. Foundation)
  258.  
  259. /*
  260.  * This procedure will ensure that, if a dialog window is being mapped,
  261.  * its contents become visible before returning.  It is intended to be
  262.  * used just before a bout of computing that doesn't service the display.
  263.  * You should still call XmUpdateDisplay() at intervals during this
  264.  * computing if possible.
  265.  *
  266.  * The monitoring of window states is necessary because attempts to map
  267.  * the dialog are redirected to the window manager (if there is one) and
  268.  * this introduces a significant delay before the window is actually mapped
  269.  * and exposed.  This code works under mwm, twm, uwm, and no-wm.  It
  270.  * doesn't work (but doesn't hang) with olwm if the mainwindow is iconified.
  271.  *
  272.  * The argument to ForceDialog is any widget in the dialog (often it
  273.  * will be the BulletinBoard child of a DialogShell).
  274.  */
  275.  
  276. ForceDialog(w)
  277.      Widget w;
  278. {
  279.   Widget diashell, topshell;
  280.   Window diawindow, topwindow;
  281.   Display *dpy;
  282.   XWindowAttributes xwa;
  283.   XEvent event;
  284.   XtAppContext cxt;
  285.  
  286. /* Locate the shell we are interested in.  In a particular instance, you
  287.  * may know these shells already.
  288.  */
  289.  
  290.   for (diashell = w;
  291.        !XtIsShell(diashell);
  292.        diashell = XtParent(diashell))
  293.     ;
  294.  
  295. /* Locate its primary window's shell (which may be the same) */
  296.  
  297.   for (topshell = diashell;
  298.        !XtIsTopLevelShell(topshell);
  299.        topshell = XtParent(topshell))
  300.     ;
  301.  
  302.   if (XtIsRealized(diashell) && XtIsRealized(topshell)) {
  303.     dpy = XtDisplay(topshell);
  304.     diawindow = XtWindow(diashell);
  305.     topwindow = XtWindow(topshell);
  306.     cxt = XtWidgetToApplicationContext(diashell);
  307.  
  308. /* Wait for the dialog to be mapped.  It's guaranteed to become so unless... */
  309.  
  310.     while (XGetWindowAttributes(dpy, diawindow, &xwa),
  311.            xwa.map_state != IsViewable) {
  312.  
  313. /* ...if the primary is (or becomes) unviewable or unmapped, it's
  314.    probably iconified, and nothing will happen. */
  315.  
  316.       if (XGetWindowAttributes(dpy, topwindow, &xwa),
  317.           xwa.map_state != IsViewable)
  318.         break;
  319.  
  320. /* At this stage, we are guaranteed there will be an event of some kind.
  321.    Beware; we are presumably in a callback, so this can recurse. */
  322.  
  323.       XtAppNextEvent(cxt, &event);
  324.       XtDispatchEvent(&event);
  325.     }
  326.   }
  327.  
  328. /* The next XSync() will get an expose event if the dialog was unmapped. */
  329.  
  330.   XmUpdateDisplay(topshell);
  331. }
  332.  
  333.  
  334. -----------------------------------------------------------------------------
  335. Subject: 97) How can I control placement of a popup widget?  Each time a popup
  336. is created, it is placed in or over the middle of its parent.  How can I make
  337. it obey the XmNx and XmNy values?
  338.  
  339. Answer: Set the resource XmNdefaultPosition for the popup to False.  Set the
  340. position of the popup by the resource values of XmNx and XmNy.  Do not use
  341. XtMoveWidget, as this is for widget writers only.  Here's a demo program from
  342. Dan Heller:
  343.  
  344. /* Written by Dan Heller.  Copyright 1991, O'Reilly && Associates.
  345.  * This program is freely distributable without licensing fees and
  346.  * is provided without guarantee or warranty expressed or implied.
  347.  * This program is -not- in the public domain.  This program is
  348.  * taken from the Motif Programming Manual, O'Reilly Volume 6.
  349.  */
  350.  
  351. /* map_dlg.c -- Use the XmNmapCallback to automatically position
  352.  * a dialog on the screen.  Each time the dialog is displayed, it
  353.  * is mapped down and to the right by 200 pixels in each direction.
  354.  */
  355. #include <Xm/MessageB.h>
  356. #include <Xm/PushB.h>
  357.  
  358. /* main() --create a pushbutton whose callback pops up a dialog box */
  359. main(argc, argv)
  360. char *argv[];
  361. {
  362.     Widget toplevel, button;
  363.     XtAppContext app;
  364.     void pushed();
  365.  
  366.     toplevel = XtVaAppInitialize(&app, "Demos",
  367.         NULL, 0, &argc, argv, NULL, NULL);
  368.  
  369.     button = XtCreateManagedWidget("button", xmPushButtonWidgetClass,
  370.         toplevel, NULL, 0);
  371.     XtAddCallback(button, XmNactivateCallback, pushed, "Hello World");
  372.  
  373.     XtRealizeWidget(toplevel);
  374.     XtAppMainLoop(app);
  375. }
  376.  
  377. /* callback function for XmNmapCallback.  Position dialog in 200 pixel
  378.  * "steps".  When the edge of the screen is hit, start over.
  379.  */
  380. static void
  381. map_dialog(dialog, client_data, cbs)
  382. Widget dialog;
  383. XtPointer client_data;
  384. XmAnyCallbackStruct *cbs;
  385. {
  386.     static Position x, y;
  387.     Dimension w, h;
  388.  
  389.     XtVaGetValues(dialog, XmNwidth, &w, XmNheight, &h, NULL);
  390.     if ((x + w) >= WidthOfScreen(XtScreen(dialog)))
  391.         x = 0;
  392.     if ((y + h) >= HeightOfScreen(XtScreen(dialog)))
  393.         y = 0;
  394.     XtVaSetValues(dialog, XmNx, x, XmNy, y, NULL);
  395.     x += 200, y += 200;
  396. }
  397.  
  398. /* pushed() --the callback routine for the main app's pushbutton.
  399.  * Create and popup a dialog box that has callback functions for
  400.  * the Ok, Cancel and Help buttons.
  401.  */
  402. void
  403. pushed(w, message)
  404. Widget w;
  405. char *message; /* The client_data parameter passed by XtAddCallback */
  406. {
  407.     Widget dialog;
  408.     Arg arg[3];
  409.     XmString t = XmStringCreateSimple(message);
  410.     extern void response();
  411.  
  412.     XtSetArg(arg[0], XmNautoUnmanage, False);
  413.     XtSetArg(arg[1], XmNmessageString, t);
  414.     XtSetArg(arg[2], XmNdefaultPosition, False);
  415.     dialog = XmCreateMessageDialog(w, "notice", arg, 3);
  416.     XmStringFree(t);
  417.  
  418.     XtAddCallback(dialog, XmNmapCallback, map_dialog, NULL);
  419.  
  420.     XtManageChild(dialog);
  421.     XtPopup(XtParent(dialog), XtGrabNone);
  422. }
  423.  
  424.  
  425. -----------------------------------------------------------------------------
  426. Subject: 98) TOPIC: LANGUAGE BINDINGS
  427.  
  428. -----------------------------------------------------------------------------
  429. Subject: 99)*  Is there a C++ binding for Motif?
  430. [Last modified: November 92]
  431.  
  432.  
  433. Answer: WWL is a library which defines C++ classes around X Toolkit Widgets.
  434. It is intended to simplify the task of C++ code writers when using the Toolkit
  435. by providing them with C++ objects, methods, type checking and several utility
  436. functions and classes.
  437.  
  438. WWL has been tested under SunOs4.0.3 on sun3 and sun4, HPUX version 6.5 and
  439. 7.0 and Ultrix 4.0 on DECstation 3100 and 5000. It is expected to work on most
  440. other UNIX systems without too many problems.
  441.  
  442. WWL is distributed as a tar file with all the source, documentation and
  443. example. The file is available using anonymous ftp from
  444.  
  445.         export.lcs.mit.edu (18.30.0.238   contrib/WWL-1.0.tar.Z
  446.         lri.lri.fr (129.175.15.1)      pub/WWL-1.0.tar.Z
  447.  
  448.  
  449. Answer: Rogue Wave Software has a C++ binding for Motif called View.h++.
  450.  
  451. "View.h++ is a complete C++ interface to OSF/Motif.  It doesn't just
  452. encapsulate it, but also includes a set of classes that provide a level of
  453. abstraction above Motif, thus simplifying menu and dialog creation, XmStrings,
  454. XmFontLists, etc.  View.h++ supports a Model- View-Controller architecture,
  455. allowing for an even more object-oriented interface design.  Includes a copy
  456. of Rogue Wave's Tools.h++ (foundation class library)"
  457.  
  458. An object license is $795 "per seat" and a source code license is available
  459. for $2,995 "per seat."  Rogue Wave also offers full support for View.h++.
  460.  
  461. It is currently available for Sun Sparc, IBM RS/6000, HP 9000/700 series, SCO,
  462. Intel SVR4 ESIX.  Please call for Silicon Graphics and DEC Ultrix status.
  463.  
  464. For additional information, please contact:
  465.  
  466. Matt Steinauer
  467. Rogue Wave Software, Inc.
  468. P.O. Box 2328
  469. Corvallis, OR 97339
  470. Phone: (503)754-3010
  471. Fax:   (503)757-6650
  472.  
  473. email:   matts@roguewave.com
  474.  
  475.  
  476. Answer: From Andreas.Baecker@gmd.de: The GINA++ application framework contains
  477. an encapsulation of the OSF/Motif widg et classes and the Xt functionality
  478. into C++ classes. Its functionality is comparab le to that of the ULowell
  479. binding and the WWL. Additionally, it provides an easy-to -use framework for
  480. modeling new composite and primitive widget classes, plus an application
  481. framework similar to ET++ or MacApp build on top of it. The binding may be
  482. used independently from the framework classes. GINA++ is available through
  483. anonymous ftp from ftp.gmd.de [129.26.8.90] in the directory /gmd/ginaplus.
  484. Documentation about the Motif binding has been published in the X Resource
  485. Journ al, Number 2, 1992, Pages 106-130. The binding compiles with AT&T C++
  486. 2.1 and GNU G+ + 2.1 and has been tested on SunOS 4.1.[12], X11R4 and Motif
  487. 1.1.3.
  488.  
  489. Answer: Motif++ is a library that defines C++ class "wrappers" for the widgets
  490. defined in the OSF/Motif-1.1 widget library. Motif++ is also an application
  491. toolkit that provides other tools in conjunction with the widget wrapper
  492. classes.  It has support for the Xbae widget set, plus other widgets.  It has
  493. Imake support, and lots of test files.
  494.  
  495. Motif++ is very similar to other public domain widget libraries such as The
  496. Widget Wrapper Library (WWL) and the C++ Binding for OSF/Motif developed at
  497. the Univeristy of Lowell. The two latter libraries are the result of much
  498. larger efforts.
  499.  
  500. Availability:
  501.  
  502. Anonymous ftp at decuac.dec.com (192.5.214.1), directory /pub/X11,
  503. file motif++.21.jul.92.tar.Z (855293 bytes).
  504.  
  505. For more information, contact Ronald van Loon (rvloon@cv.ruu.nl)
  506.  
  507.  
  508. Answer: The Solbourne OI toolkit (not Motif) also has a C++ binding.
  509.  
  510. Answer: Doug Young has written a book "Object Oriented Programming with C++
  511. and Motif", Prentice-Hall ISBN 0-13-630252-1 about using C++ without requiring
  512. one of these toolkits.
  513.  
  514. -----------------------------------------------------------------------------
  515. Subject: 100)+ How can I have a C++ member function in a callback?
  516.  
  517. [Last modified: November 92]
  518.  
  519. Answer: Motif++ has a nice tutorial summarising mechanisms. Doug Young's book
  520. deals extensively with one of these. The problem is that you don't get the
  521. object when you just use the function as a callback.  You need to pass the
  522. object as a pointer through as the client_data.  (use "this" as the
  523. client_data.) Then you can retrieve the object's address, and dereference from
  524. there. For example (Leo O'Donnell, Email: leo@avs.com),
  525.  
  526.     class MyButton {
  527.       public:
  528.                 MyButton (Widget parent, const char *name) {
  529.                     _button = XtVaCreateManagedWidget (
  530.                         name, xmPushButtonWidgetClass, parent, NULL, 0);
  531.                     XtAddCallback (
  532.                         _button,
  533.                         XmNactivateCallback,
  534.                         &MyButton::activateCB,
  535.                         (XtPointer) this);
  536.                 }
  537.                 ~MyButton () { XtDestoryWidget (_button); }
  538.       private:
  539.         Widget  _button;
  540.         static  void activateCB (Widget, XtPointer, XtPointer);
  541.     };
  542.  
  543.     void MyButton::activateCB (Widget, XtPointer thisBtn, XtPointer)
  544.     {
  545.         MyButton *btn = (MyButton *) thisBtn;
  546.  
  547.         // OK you've got the button instance now. Do some stuff with it!
  548.     }
  549.  
  550.  
  551.  
  552. -----------------------------------------------------------------------------
  553. Subject: 101)* Is there a Common Lisp binding for Motif?
  554.  
  555. [Last modified: November 92]
  556.  
  557. Answer: Try CLM. This includes a toolkit demon (in C) that takes a widget
  558. description (with callbacks), and forks a new process for each Motif
  559. application (which can be just a single menu, or whatever).  Lisp can then
  560. continue running, with a separate lightweight lisp process handling the
  561. connection & callbacks.  In North America & net environs, CLM-2.0beta is
  562. available from export.lcs.mit.edu.
  563.  
  564. There is also CLIM, the Common Lisp Interface Manager. It provides access to
  565. motif and other toolkits and window systems.  Here is some blurb: "Version 2.0
  566. of the Common Lisp Interface Manager (CLIM) provides access to Motif. CLIM is
  567. the emerging standard for GUI development in Common Lisp.  It offers a set of
  568. high-level facilities that enable rapid construction of user interfaces.
  569. Applications written using CLIM are portable across a variety of window
  570. systems and toolkits.  For example, on the X window System, both Motif
  571. (OSF/Motif) and Openlook (OLIT) are supported.  CLIM accesses the toolkit
  572. directly rather than emulating the look and feel."
  573.  
  574. CLIM is available from a variety of Common Lisp vendors including Symbolics
  575. and Franz Inc. (info@franz.com).
  576.  
  577.  
  578. -----------------------------------------------------------------------------
  579. Subject: 102)  Is there an Ada binding for Motif?
  580.  
  581. Answer:
  582.  
  583. From Todd W. Lainhart: Take a look at THINGS, a VAPI with Ada bindings that
  584. was written by the US Air Force (SAC).  It's in the public domain, and
  585. available from export or gatekeeper.dec.com.  It implements Motif or OL look-
  586. and-feel. [I had a look and it seemed to be missing documentation - Jan]
  587.  
  588. From David Lewis: A company called Rational appears to be making an Xm
  589. implementation.  Also GHG in Texas has most other Xlib and Xt bindings for
  590. Ada.
  591.  
  592. From comp.windows.x FAQ: Ada bindings to Motif, explicitly, will eventually be
  593. made available by the Jet Propulsion Laboratories, probably through the normal
  594. electronic means.  Advance information can be obtained from
  595. dsouleles@dsfvax.jpl.nasa.gov, who may respond as time permits.  Another set
  596. of bindings for Motif is being done by the University of Lowell; information
  597. is available from osfri@osf.org.[11/90]
  598.  
  599. TeleSoft has bindings for Motif, Xt and Xlib.  They are called TeleWindows.
  600. Contact their customer support department for more information.
  601.  
  602.      TeleSoft
  603.      5959 Cornerstone Court West
  604.      San Diego, CA 92121-9891
  605.      +1 619-457-2700
  606.      +1 619-452-1334 Fax
  607.  
  608.      Email: adasales@telesoft.com (Sales)
  609.             adasupport@telesoft.com (Customer Support)
  610.  
  611.  
  612. TAE Plus will generate either Ada or C. Contact
  613.  
  614.         Goddard Space Flight Center
  615.         TAE Suppport Office
  616.         Code 522
  617.         Attn: Arleen Yeager
  618.         Greenbelt, MD  20771
  619.         301-286-6034
  620.         FTS 888-6034
  621.  
  622.         e-mail:  taeso@postman.gsfc.nasa.gov
  623.  
  624.         TELEMAIL from a NASA facility:      TELEMAIL outside of NASA:
  625.         [TAESO/GSFCMAIL]GSFC                [TAESO/GSFCMAIL]GSFC/USA
  626.         SPAN is 6162::TAESO
  627.  
  628. SA-Motif is a complete binding to X Window and Motif for the Ada; it is based
  629. in part upon the SAIC/Unisys bindings. SA-Motif is available on the Sun3,
  630. Sun4,  SCO, HPUX, and SGI IRIX. Info: Systems Engineering Research
  631. Corporation, 2348 Leghorn Street, #202/Mountain View, CA 94043/1-800-Ada-SERC
  632. (well!serc@apple.com).
  633.  
  634.  
  635.  
  636. -----------------------------------------------------------------------------
  637. Subject: 103) TOPIC: SPECIFIC PLATFORMS
  638.  
  639. -----------------------------------------------------------------------------
  640. Subject: 104) Is it easy to build Motif for a Sun?
  641.  
  642. Answer: No pattern has emerged to problems about compiling Motif on the Sun
  643. (although people seem to have a lot of different minor problems), and many
  644. reports are that it is straightforward. Read the Motif install instructions
  645. (which often have specific reference to Sun installation), light the blue
  646. touch paper and just standback. [My experience was that I had to add
  647. -D_NO_PROTO for 1.1 on a Sparc OS 4.1, and that was all.  Others have added
  648. STRINGS_ALIGNED and NO_REGEXP].
  649.  
  650.  
  651. -----------------------------------------------------------------------------
  652. Subject: 105) What compile errors/warnings might I get in both Sun 3 and Sun
  653. 4?
  654.  
  655. Answer:
  656.  
  657.  
  658. make: Warning: Too many rules defined for target
  659. make: Warning: Too many rules defined for target
  660. "callbacks.c", line 1530: warning: illegal combination of pointer
  661. and integer, op =
  662. "callbacks.c", line 1531: warning: illegal combination of pointer
  663. and integer, op =
  664. "callbacks.c", line 1532: warning: illegal combination of pointer
  665. and integer, op =
  666. "utils.c", line 73: warning: illegal combination of pointer and integer, op =
  667. "utils.c", line 74: warning: illegal combination of pointer and integer, op =
  668. "utils.c", line 122: warning: illegal combination of pointer and integer, op =
  669. "utils.c", line 123: warning: illegal combination of pointer and integer, op =
  670. "utils.c", line 191: warning: illegal combination of pointer and integer, op =
  671. "utils.c", line 194: warning: illegal combination of pointer and integer, op =
  672. "utils.c", line 195: warning: illegal combination of pointer and integer, op =
  673. "utils.c", line 196: warning: illegal combination of pointer and integer, op =
  674. "utils.c", line 316: warning: illegal combination of pointer and integer, op =
  675. "utils.c", line 334: warning: illegal combination of pointer and integer, op =
  676. "utils.c", line 338: warning: illegal combination of pointer and integer, op =
  677. "utils.c", line 341: warning: illegal combination of pointer and integer, op =
  678. "xmdialogs.c", line 838: warning: illegal combination of pointer
  679. and integer, op =
  680. "xmeditor.c", line 1152: warning: illegal combination of pointer
  681. and integer, op =
  682.  
  683. These warning messages can be ignored. OSF is aware of these warnings.
  684.  
  685.  
  686. -----------------------------------------------------------------------------
  687. Subject: 106) On a Sun 3, what are the mwm startup error messages about?  I
  688. get
  689.  
  690. mwm: Invalid accelerator specification on line 7 of
  691.      specification string
  692. mwm: Invalid accelerator specification on line 31 of
  693.       configuration file
  694.  
  695.  
  696. Answer: This is because some Sun keyboards do not have an F10 key and some sun
  697. workstations which have an F10 key do not have X-servers which recognize it.
  698. The F10 key is used by mwm.  If the machine does have an F10 key, the user
  699. should use xmodmap to tell the server it exists.  Otherwise, change the
  700. definition of the DefaultWindowMenu in /usr/lib/X11/system.mwmrc (after
  701. installation) or in /lib/clients/mwm/system.mwmrc (before installation).
  702. Change the accelerator of "Maximize" (it is "Alt<Key>F10)" to something else.
  703. Also, you should change the definition of DEFAULTSYSTEMMENU in the file
  704. /clients/mwm/WmResource.c in a similar fashion.  There is as yet no standard
  705. redefinition for F10.
  706.  
  707.  
  708.  
  709. -----------------------------------------------------------------------------
  710. Subject: 107) Are there problems making shared libraries on a Sun?
  711.  
  712. Answer: If you use the -pic option you may run out of offset table space.  use
  713. the -PIC option instead.
  714.  
  715. You may get the message "ld.so: Undefined symbol: __XtInherit" when executing
  716. UIL. There is a problem in shared library build when you compare a function
  717. variable to a routine name, but don't call the routine.  Either, you can build
  718. the Xt library nonshared, or you can put a reference to XtToolkitInitialize in
  719. the UIL main program (or even include a module that references it).  The
  720. routine doesn't even have to be called; it just has to be there.
  721.